Blog Post

Storage at Microsoft
4 MIN READ

SMB NTLM blocking now supported in Windows Insider

NedPyle's avatar
NedPyle
Icon for Microsoft rankMicrosoft
Sep 13, 2023

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25951 (Canary) and Windows Server Preview Build 25951, the SMB client now supports blocking NTLM for remote outbound connections. This changes legacy behavior, where Windows SPNEGO would negotiate Kerberos, NTLM, and other mechanisms with the destination server to decide on a supported security package. NTLM in this case refers to all versions of the LAN Manager security package: LM, NTLM, and NTLMv2.

 

With this new option, an administrator can intentionally block Windows from offering NTLM via SMB. An attacker who tricks a user or application into sending NTLM challenge responses to a malicious server will no longer receive any NTLM data and cannot brute force, crack, or pass hashes. This adds a new level of protection for enterprises without a requirement to entirely disable NTLM usage in the OS.

 

Note: This setting has no effect on loopback SMB NTLM usage, i.e. mapping a drive locally on a device with a local account.

 

Update April 3, 2024: official documentation now available at Block NTLM connections on SMB (preview) | Microsoft Learn.

 

Update Oct 11, 2023: We also just announced that a new local KDC is coming to Windows Insider Previews along with a replacement for KDC Proxy called IAKerb. These combined options mean the beginning of the end for NTLM. Read about it at The evolution of Windows authentication.    

 

Update November 8, 2023:

Starting with Build 25992, the new SMB NTLM blocking feature now supports specifying exception lists for NTLM usage. This allows an administrator to configure a general block on NTLM usage while still allowing clients to use NTLM for specific servers that do not support Kerberos, either because they are not Active Directory domain joined or are a third party without Kerberos support.

 

Configuring SMB NTLM Blocking

You can configure this option with Group Policy and PowerShell. You can also block NTLM SMB connections on demand with NET USE and PowerShell. 

 

Group Policy

To configure SMB NTLM blocking for the entire Windows machine, enable the group policy under:

 

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Block NTLM (LM, NTLM, NTLMv2)

 

gpedit showing the group policy setting

 

To configure SMB NTLM blocking with exceptions for certain remote devices, enable the group policy under:

 

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Block NTLM Server Exception List

 

You can then add IP addresses, fully qualified DNS, and NetBIOS names of remote machines where you want SMB to allow NTLM authentication.

 

gpedit.msc

PowerShell (global)

To configure SMB NTLM blocking for the entire Windows machine with PowerShell, set with the following syntax:

 

Set-SMbClientConfiguration -BlockNTLM $true 

 

NET USE

To specify SMB NTLM blocking when mapping a drive with NET USE, use the following syntax:

 

NET USE \\server\share /BLOCKNTLM

 

New-SmbMapping

To specify SMB NTLM blocking when mapping a drive with PowerShell, use the following syntax:

 

New-SmbMapping -RemotePath \\server\share -BlockNTLM $true

 

Troubleshooting SMB NTLM Blocking

Connecting to Active Directory domain-joined computers with SMB while using a domain user account should always result in Kerberos authentication. Blocking NTLM should have no consequences to connectivity in this case. If you are expecting Kerberos to work when blocking NTLM and you are unable to connect, this section will help troubleshoot.

 

When NTLM is expected

You should expect NTLM usage under the following circumstances:

 

  1. The client connects using an IP address. 
  2. The Kerberos CIFS Service Principal Name is missing in AD for the SMB server.
  3. The credential used for the SMB server is a local user account.

The possible errors shown when NTLM blocking is preventing connection are:

 

67

0x43

ERROR_BAD_NET_NAME                                            

The network name cannot be found

 

Troubleshooting

If you expect to connect but NTLM blocking is preventing you, use the following steps:

 

  1. Verify that NTLM blocking is the culprit by temporarily disabling it on the client. The nature of NTLM blocking's current errors in Windows Insider means that it is easy to confuse NTLM blocking with unrelated networking problems like DNS name resolution.
  2. If connecting with IP address, switch to using a fully-qualified domain name. To use IP addresses with Kerberos, review Configuring Kerberos for IP Address.
  3. Verify the destination SMB server has its HOST SPN records registered by using SETSPN -L SMBSERVERNAME. For example:

setspn -L FS2
Registered ServicePrincipalNames for CN=FS2,CN=Computers,DC=corp,DC=contoso,DC=com:
WSMAN/fs2
WSMAN/fs2.corp.contoso.com
TERMSRV/FS2.corp.contoso.com
RestrictedKrbHost/FS2.corp.contoso.com
HOST/FS2.corp.contoso.com
TERMSRV/FS2
RestrictedKrbHost/FS2
HOST/FS2

 

If still unable to connect, use a network capture tool like Wireshark to examine the client and server messages for DNS, SMB2, and Kerberos.

 

Final notes

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

 

 

For more information on securing SMB on Windows in-market, check out:

 

 

Until next time,

 

Ned Pyle

Updated Jul 02, 2024
Version 14.0
  • ajf8729 yes, that older setting applies to ALL network protocols. The new one just applies to SMB specifically. So the old one includes SMB (and RPC, LDAP, etc.), the new one is just SMB.

  • AMateos91's avatar
    AMateos91
    Iron Contributor

    Thanks for sharing.

    Just one modest suggestion: would it triggering and insteresting to enlarge the Group Policy implementations to other tools, such as the integration of Git package?

     

    Thanks and best.

  • mjdavison's avatar
    mjdavison
    Copper Contributor

    With the release of 24H2, we've started testing this feature, and have discovered a slightly odd behaviour that means we cannot currently enable this.

     

    For our endpoint admin users, we can no longer access shares when this setting is enabled. This is the case even on devices where outbound NTLM is already blocked system-wide.

     

    The users involved have the following properties.

     

    1. Smart-Card only set on user object.

    2. Account set as not delegated on user object.

    3. User is a member of Protected Users. 

    4. Local administrator on the client device.

     

    The behaviour is as follows.

     

    1. If System-Wide NTLM Blocking (restrictsendingntlmtraffic) is enabled, the issue does not occur, and the share can be accessed.

    2. If SMB-only NTLM Blocking is additionally enabled, the share cannot be accessed, Event 4015 is logged, and a message of "Authentication failed because NTLM authentication has been disabled." is received.

     

    Is this expected behaviour for this feature?